Looks good and is a simple and safe fix.

However, since it only targets a specific scenario (one element in selection), I am afraid we may need to revisit it.

The problem with current implementation is that it only looks at elementEnd while it seems it could look at elementStart as well. If the treewalker traverses over elementStart and this is a top-most unvisited block element, we should "jump" over it, as we never return blocks inside blocks:

 * **Note:** `getSelectedBlocks()` returns blocks that are nested in other non-block elements
 * but will not return blocks nested in other blocks.

Of course, we should respect this special case that is mentioned later:

* **Special case**: Selection ignores first and/or last blocks if nothing (from user perspective) is selected in them.

Maybe it's even possible to limit the number of isUnvisitedTopBlock() calls with some smart observations, but what I proposed seems like a safe change as well. One difficulty is that, AFAIR, it is not possible currently to change TreeWalker#position. There is .skip() but it simply traverses the tree, so that's exactly what we want to avoid. We would need something like .jumpToPosition( position ) and this should basically reset the treewalker and set it to that position. Alternatively, we could create a new treewalker and overwrite the current one.

I implemented the suggestions. The jumpTo will not prevent tree walkers from going out of boundary, which is best described here: